Method for implementing content delivery network (cdn) internetworking, respective networks and interface component

ABSTRACT

Internetworking of a set of Content Delivery Networks CDN (CDN 1 , CDN 2 ) is obtained by employing interface components intended to be each associated to a network (CDN 1 ) in the set and co-operating according to a Content Internetworking Gateway (CIG) another components association the set of said interface Services or Domain Name networks. Access of internetworking networks through the Directory Name Service or Domain Name Server (DNS) of the respective network. with at least one (CDN 2 ) of the collect routing data referred similar component in set. Said interface to the them in transferred by Directory Name the respective the contents of network (CIG) of contents and caches which contain networks. The routing components (CIG) Servers clients (CDN 1 , CDN 2 ) is thus implemented through the Directory Name Service or Domain Name Server (DNS) of the respective network.

TECHNICAL FIELD

This invention relates in general to techniques generally known as“internetworking”.

In general terms, the basic objective of internetworking is theco-operation and interoperability of elementary systems (seen as “blackboxes”) to create a macrosystem capable of presenting thecharacteristics of the constituent systems with the addition of a numberof advantages.

BACKGROUND ART

Firstly, when two or more different administrative entities reach aninternetworking agreement they extend (within contractual limits) theirrespective catchment areas without additional expenses for wiring orstructural purposes. It is reasonable to think that the service qualityperceived by the final user may be increased due to the larger size ofthe reference network.

In the specific case of the so-called Content Delivery Networks, orCDNs, additional contents and diversification is also provided.

For its very nature, an internetworking solution requires the presenceof interface components which, on elementary system (i.e. single CDN)side have a complete overview of the evolution of the static and dynamiccharacteristics and which on the “rest of the world” side (i.e. on theside of the other internetworking networks, that is on peer side) haveonly the comprehensive information needed to establish profitableintersystem communication. The term “profitable” here means efficient,safe and reliable being provided with the mechanisms that this type ofsolution entails.

Regulations concerning the matter are currently being drawn up, asdocumented, for example, by the following draft standards published byIETF (Internet Engineering Task Force) which can be retrieved from theorganisation's web site, namely:

-   -   “A Model for CDN Peering”, by M. Day, B. Cain, G. Tomlinson        and P. Rzewski, May 2001;    -   “Content Internetworking Architectural Overview”, by M.        Green, B. Cain, G. Tomlinson, S. Thomas e P. Rzewski, March        2001;    -   “Known Mechanisms for Content Internetworking”, by F.        Douglis, I. Chaudhri and P. Rzewski, November 2001.

The interface components are called Content Internetworking Gateways orCIGs. CIGs have a complete overview of the environment within theirrespective CDN and perceive the data related to remote environmentsthrough protocols for exchanging data, called “advertisements”.

From an abstract point of view, a CIG must route requests (i.e. performrequest-routing functions), on the basis of all data from thepre-existing infra-CDN modules (distribution system and monitoringsystem) and equivalent remote devices.

According to the aforesaid standards, the CIG routes a client's contentrequests.

Specifically, having received a request for a certain content and havingverified that the content is available in its respective CDN, the CIGsends the corresponding required content cache ID to the client. Theconcerned CIG is consequently capable of routing the request, also whenthe content is hosted in the cache of another CDN.

In this situation, when several CDN networks are internetworking, theCIGs perform address resolution and content request-routing functions,which on internet level are remitted to other network members,particularly by involving the so-called DNS (Directory Name Service orDomain Name Server).

This leads to splitting/duplication of functions which causes severalproblems. The problems are related, among other, to the need of ensuringcorrect synchronisation between CIGs and devices in the Internet and tothe fact that the request from a certain client is processed differentlyaccording to whether the request involves the CDN level or not.

DISCLOSURE OF THE INVENTION

The object of the invention is to overcome these shortcomings.

The object is obtained according to the invention thanks to a procedurewhose characteristics are recited in the annexed claims. The inventionalso relates to a corresponding system of internetworking CDN networksand a respective interface or CIG component.

BRIEF DESCRIPTION OF DRAWINGS

The invention will now be described, by way of example only, withreference to the accompanying drawings wherein:

FIG. 1 generally illustrates the internetworking organisation criteriaof two CDN networks,

FIG. 2 generally illustrates the structures of a Content InternetworkingGateway, or CIG, according to the invention,

FIGS. 3 and 4 illustrate different infra-CDN and inter-CDNrequest-routing methods,

FIGS. 5 to 7 illustrate the typical CIG context diagrams at variouslevels detail according to the invention,

FIG. 8 shows the finite state automaton of a corresponding CIG,

FIG. 9 is a time diagram showing the opening of a corresponding session,and

FIGS. 10 to 13 illustrate the format of the various messages exchangedby a CIG according to the invention.

BEST MODE FOR CARRYING OUT THE INVENTION

The diagram in FIG. 1 illustrates the collocation of two ContentInternetworking Gateways (hereinafter called CIG for short) intended topermit exchange of “advertisement” data in the context of a set formedby two Content Delivery Networks CDN1 and CDN2 in combination with anOrigin Server (OS) each.

Each CDN shown here consists of a respective administrative domain witha Directory Name Service or Domain Name Server (DNS for short),management centre, cache memories and connections to client functionterminals.

FIG. 1 shows the role of the CIGs in the internetworking process. One ofthe specific characteristics of a CIG is the degree (or level) ofintegration, as a parameter, respect to the modules which are alreadypresent and operational within a CDN.

The higher or lower efficiency of the respective interface functions canbe assessed according to this parameter.

FIG. 2 briefly illustrates the interface components which form a CIGaccording to the invention in the currently preferred form ofembodiment.

Specifically, the concerned CIG consists of:

-   -   a first interface module, called Request-Routing Interface or        RRI, which exchanges data with the remote CIGs according to CNAP        protocol specifications (described in detail in the description        that follows),    -   a second interface module, called DNS Interface or DNSI, which        interfaces with the DNS of the CDN to which the CIG belongs,    -   a third interface module, called Distribution Information        Interface, or DII, which retrieves data on the availability of        contents from the distribution system of the CDN to which the        CIG belongs,    -   a forth interface module, called Monitoring Information        Interface, or MII, which interacts with the monitoring system,        and finally    -   a central module, called Request-Routing Process, or RRP, which        collects and processes the information received to implement the        request-routing function: the latter module is the CIG core.

It is noted that the aforesaid architecture, although preferred, is notabsolutely imperative or binding, at least as concerns the presence ofthe third or fourth interface module described above.

Further reference to the CNAP protocol may be found in “Content NetworkAdvertisement Protocol (CNAP)” by B. Cain, O. Spatscheck, L. Amini, A.Barbir, M. May and D. Kaplan, November 2001, which may also be retrievedfrom the IETF web site.

Briefly, the CIG consists of a central module which is the “brain” ofthe device and a certain number of interface modules between the CIG andthe pre-existing infrastructure.

The described request-routing technique solution refers to modulesimplementing DNS technology.

Consequently, two likely internetworking scenarios may be hypothesisedand illustrated in an event trace diagram.

FIG. 3 shows a classical content routing scenario, so to speak, the termherein indicating a standard routing process in a CDN (implementing DNStechnology) in which DNS table updating is delegated to the CIG by meansof the DNSI module.

Extending the example to an actual internetworking case is easy withthis procedure.

The labels and the directions of the arrows in the figures help tounderstand the real sequence of events: a user makes a content requestto the DNS system which works in standard mode. The DNS responds withthe best surrogate IP address according to the routing policies appliedat the time. The CIG periodically updates the DNS tables, according tothe information received from the distribution and monitoring system;note that in this first case, the system is “isolated”, so to speak.

Conversely, in the situation in FIG. 4, the selected surrogate serversbelong to another administrative domain, i.e. CDN. The dynamics appearsessentially similar to the example above. In this case, as above, theclient queries the DNS which replies with the best surrogate server IPaddress. The difference is in the data retrieving and updating method.The bi-directional arrows in the central section indicate the periodicalexchange of routing data between entities on the same hierarchic level(peers), i.e. the CIGs, according to the conventions and thespecifications of the CNAP protocol. This type of data is similar toinfra-CDN data, and used by a CIG to update the DNS tables on the basisof a wider range of data with respect to that which occurs in knownarchitectures.

The roles of the modules which form a CIG operating according to theinvention will now be described with reference to the diagram indicatedby the acronym DFD (Data Flow Diagram).

The higher level approach consists in the use of a so-called contextdiagram. The diagram represents the interactions between the whole CIGand the “outside world”. As shown, the CIG appears as a single entitycapable of interacting with the rest of the world.

The CIG routes requests according to the information from the otherentities with which it communicates. More in detail, it receives datafrom peers, from the distribution system and the local monitoringsystem. After processing, the data, the DNS tables and the log filearchives are updated.

At this point, the request-routing system can be observed closer, bysplitting into subsystems and representing the functions on differentlevels of detail. Two subsequent expansions are illustrated in FIG. 6and FIG. 7, respectively.

Specifically, the interface processes clearly appear in FIG. 6,corresponding to a first level of detail: these are “buffer” moduleswhich communicate with the central process on one side and with theoutside world on the other.

FIG. 7, on the other hand, illustrates the functions of the RRP core.The RRP receives data from the rest of the world and transmits them viathe interfaces, extracts useful information on cache and/or contentstate, evaluates the need to update and consequently modifies its owndatabase, the DNS tables and the log file archives. Finally, ifrequired, it sends the message to its peers, through the request-routinginterface RRI.

The request-routing interface RRI interfaces with the rest of the world.From this point of view, it is the most important module in theinternetworking procedure, because it is directly implied in inter-CDNcommunication; as mentioned above, this communication is carried outaccording to the conventions of the CNAP protocol which was designed forthis purpose.

This module is responsible for translating the messages from CNAP(inter-CDN) format to a format which can be understood by the CIG(infra-CDN) central process, or RRP. The CNAP protocol requires initialspecifications (and periodical updating) or a set of data, which arestatic so to speak, referred to the internetworking system topologycharacteristics. For example, the following may be requested:

-   -   the local CNAS ID (i.e. the CDN to which the concerned CIG        belongs);    -   the IP address of the local CIG computer;    -   the CNAS IDs of remote interconnected systems (peers) with which        internetworking will be established;    -   the IP addresses of the remote CIG computers corresponding to        the systems mentioned in the point above;    -   the inter-CNAS level of confidences; and    -   a numeric coefficient indicating the “weight” in static        conditions of each connection (practically similar to the        geographical distance of the connection).

The protocol offers the possibility of diversifying the contractualinternetworking relations with the introduction of level of confidences.In other words, before disseminating information on availability of acontent to a remote CIG, the local CIG verifies whether the CIG isenabled to received the information according to the stipulated contact.

The CNAP connections, as required by the IETF for internetworkingprotocols, implement a reliable connection-oriented protocol ontransportation level: for example, TCP (Transmission Control Protocol),currently employed in Internet contexts, may be used.

The logical operations needed to establish a CNAP session are shownbelow.

This is carried out with specific reference to the finite stateautomaton diagram of the CIG as illustrated in FIG. 8.

During the initial state of the CIG, called IDLE, there is no CNAPsession and no entity has intervened to change this situation. When theCIG intends to establish a CNAP session with a remote CIG, it sends anOPEN message and goes to OPENSENT state.

The remote, also initially in IDLE state, receives a request to open aCNAP session. It replies with a KEEPALIVE message and goes toOPENCONFIRM state.

Two cases may occur.

In the first case, the original CIG receives the KEEPALIVE messagewithin a predetermined lapse of time: in this case, it goes to READYstate and waits to send advertisement messages (i.e. messages carryinguseful data, not only metadata, as initialisation messages).

In the second case, the predetermined time-out expires before theoriginal CIG receives the expected KEEPALIVE message: in this case, itreturns to IDLE state and the communication attempt fails. In general, aNOTIFY message will inform the parties of the anomaly.

The remote CIG, having sent the following KEEPALIVE message, also goesto READY state and listens out for advertisement messages to bereceived.

The reception of a NOTIFY message makes the CIG go to IDLE state. As mayeasily be assumed from the description above, the CNAP connection isactive and efficient if both involved CIG are in READY state.

FIG. 9 shows the sequences of state which characterise opening of a CNAPsession and highlight the evolution of events in time.

The messages exchanged by the RRP core and the request-routing interfaceRRI may have the format shown in FIG. 10.

The meaning of the message fields is shown below:

-   -   URL: is the URL identifying the content of the message;    -   IP: is the IP address of the cache which distributes the        contents;    -   CNAS ID: is the ID of the CDN to which the cache belongs;    -   CACHE STATE: is the state of the cache;    -   CONTENT STATE: is the state of the content in the cache;    -   TTL: is the life time of the routing data.

The monitoring interface MII is the module which implements theinterface between the RRP core and the local monitoring system, i.e.referred to the CDN to which the CIG belongs. The data which must betransferred to the RRP refer to the CDN cache state; the term “state”here indicates quantification of the available resources.

In this perspective, the format of a message from the monitoringinterface MII may assume the appearance shown in FIG. 11.

The message has five fields whose meaning is illustrated below:

-   -   IP: the IP address of the cache to which the message refers;    -   CPU: percentage of CPU used by the cache;    -   MEM: percentage of RAM used by the cache;    -   DISC: percentage of disc used by the cache;    -   USERS: percentage of the number of connected users (in relation        to the maximum service capacity of the concerned cache).

The parameters are classical performance indicators which are used toassess the conditions of use of the cache. Messages of this type arepassed to the RRP at regular intervals of time.

The DII distribution interface is the interface module between thedistribution system and the RRP core of the CIG. The DII interfacecollects information on the presence and availability of the cachecontents. FIG. 12 shows the format of a possible message of this type.

The meaning of the fields is shown below:

-   -   URL: is the URL identifying the content to which the message        refers;    -   CACHE: is the list of IP addresses of the caches in which the        content is available;    -   LEVEL OF CONFIDENCE: is the level of confidence of the content;    -   CONTENT AVAILABILITY: indicates whether the content is available        or not;    -   CACHE STATE: is the status of the cache;    -   TTL: indicates the life time of the routing data.

Three levels of confidence can be associated to the contents, i.e.:

-   -   low—contents can be exchanged with all interconnected CDNs;    -   medium—contents can be exchanged only with CDNs which have        subscribed a MEDIUM level confidence agreement with the CDN that        owns the content; and    -   high—contents can be exchanged only with CDNs which have        subscribed a HIGH level confidence agreement with the CDN that        owns the content.

The DNS interface, indicated by DNSI, is the interface module which mustcommunicate with the DNS server, to update the tables. A possible formatof the message useful for this purpose is shown in FIG. 13.

The meaning of the respective fields is:

-   -   OP: indicates the operation to be carried out on the DNS table        (two operations are available, “add” and “delete”);    -   REG TYPE: indicates the type of register;    -   DOMAIN NAME: indicates the name of the domain to which the        message refers;    -   IP: is the address of the best cache IP address to serve the        domain above;    -   TTL: is the life time of the register.

Alternatively, the DOMAIN NAME field may contain the entire URL of thecontent to which the message refers. In this way, the DNS can directlyidentify the best cache for content delivery.

The request-routing module RRP is, as mentioned above, the core of thesystem. It is responsible for processing the data received from theaforesaid interface modules, updating the DNS tables if required via theDNSI interface and forwarding the data to the other CIGs through the RRIinterface.

It is also responsible for managing the log file archive. Given the needto enable the respective DNS to perform the address resolution function(to make content delivery factually “transparent” with respect to thepresence of a set of internetworking CDN networks), the RRP core musthave a data structure which will store the states of the local CDN andthe remote CDNs. The data structure must collect and organise the datareferred to contents available in the internetworking system context andto the caches capable of providing the contents. Data structuredefinition is periodically updated by the RRP module, in a different wayaccording to the type of message which prompted the updating process ona case-by-case basis.

Naturally, numerous changes can be implemented to the construction andembodiments of the invention herein envisaged without departing from thescope of the present invention, as defined by the following claims.

1. A method for implementing internetworking of a set of ContentDelivery Networks CDN (CDN1, CDN2), the networks in said set beingprovided with respective caches, respective Directory Name Service orDomain Name Servers (DNS) and respective content distribution systems torespective clients, as well as interface components (CIG) susceptible ofbeing each associated to a respective network (CDN1) in said set ofnetworks and co-operating with at least one similar interface component(CIG) associated to another network (CDN2) in said set of networks, themethod comprising the step of collecting in said interface components(CIG) routing data related to the association of said contents and thecaches which contain them; transferring (DNSI) said routing data from atleast one of said interface components (CIG) to the directory nameservice or domain name server (DNS) of the respective network, wherebyaccess by the client of said respective network of contents of thenetworks in said set of CDN (CDN1, CDN2) is implemented through theDirectory Name Service or Domain Name Server (DNS) of said network. 2.The method according to claim 1 wherein the following steps areperformed by at least one of said interface components (CIG): to receivedata on the state of the cache and/or the contents of the respectivenetwork, to determine whether said contents require an updating or not,and to manage said updating by performing at least one step in thefollowing group comprising: editing the respective database, editing therespective Directory Name Service tables, editing the respective logfile archive, and forwarding an update request message to said at leastone similar component.
 3. The method according to claim 2 wherein saidinterface components (CIG) communicate via a CNAP protocol.
 4. A systemcomprising a set of internetworked Content Delivery Networks CDN (CDN1,CDN2), the networks in said set being provided with respective caches,respective Directory Name Service or Domain Name Server (DNS) andrespective content distribution systems to respective clients, as wellas interface components (CIG) susceptible of being each associated to arespective network (CDN1) in said set of networks and co-operating withat least one similar interface component associated to another network(CDN2) in said set of networks, said interface components (CIG) beingconfigured to collect routing data related to the association of saidcontents and the caches which contain them, at least one of saidinterface components (CIG) being configured to transfer (DNSI) saidrouting data to the Directory Name Service or Domain Name Server (DNS)of the respective network, so that access by the client of saidrespective network to the contents of the networks in said set of CDN(CDN1, CDN2) is implemented through the Directory Name Service or DomainName Server (DNS) of said network.
 5. The system according to claim 4wherein at least one of said interface components (CIG) comprises: amodule for receiving data on the state of the cache and/or the contentsof the respective network, a module for determining whether saidcontents require an updating or not, and a module for managing saidupdating by performing at least one step in the following groupcomprising: editing the respective database, editing the respectiveDirectory Name Service tables, editing the respective log file archive,and forwarding an update request message to said at least one similarcomponent.
 6. The system according to claim 5 wherein said interfacecomponents (CIG) communicate via a CNAP protocol.
 7. The interfacecomponent (CIG) for implementing Content Delivery Network CDN (CDN1,CDN2) internetworking, the networks (CDN1, CDN2) being comprised in aset and being provided with respective caches, respective Directory NameService or Domain Name Servers (DNS) and respective content distributionsystems to respective clients, said interface component (CIG) beingsusceptible of being associated to a respective network (CDN1) in saidset of networks and co-operating with at least one similar interfacecomponent associated to another network (CDN2) in said set of networks,said interface component (CIG) being configured to collect routing datarelated to the association of said contents and the caches which containthem, said interface component (CIG) comprising: at least a firstinterface module (RRI) for exchanging data with said at least onesimilar component, a second interface module (DNSI) for interfacing withthe Directory Name Service (DNS) of the respective network, and a core(RRP) for collecting and processing the data received by the componentand routing the respective requests, whereby said interface component(CIG) is susceptible of transferring said routing data to the directoryname Service or Domain Name Server (DNS) of the respective network viasaid second interface module (DNSI).
 8. The interface componentaccording to claim 7 is configured to be controlled by a monitoringsystem and comprises: a third interface module (DII) for retrieving dataon the availability of contents from the content distribution system onthe respective network, and a fourth interface module (MII) forinteracting with said monitoring system.
 9. The interface componentaccording to claim 7 wherein said core (RRP) comprises: a module forreceiving data from said interface modules (RRI, DNSI, DII, MII) andextracting data on the status of the caches and/or of the contents ofthe respective network therefrom, a module for determining whether saidcontents require an updating or not, and a module for managing theupdating by performing at least one step in the following groupcomprising: editing the respective database, editing the respectiveDirectory Name Service tables, editing the respective log file archive,and forwarding an update request message to said at least one similarinterface component.
 10. The interface component according to claim 9said at least a first interface module (RRI) is configured tocommunicate with a first interface module of said at least one similarcomponent via CNAP protocol.
 11. The interface component according toclaim 10 wherein said at least a first interface module (RRI) isconfigured to translate from said CNAP protocol to a format which can beunderstood by a core (RRP) of said at least one similar interfacecomponent.
 12. The interface component according to claim 11 saidcommunication between said first interface module (RRI) and a firstinterface module (RRI) of said at least one similar interface componentcomprises the transmission of signals indicating quantities from thefollowing group comprising: ID of the network in which said interfacecomponent is associated, IP address of the computer hosting the localinterface component, IDs of interconnected systems via said interfacecomponent and said at least one similar interface component, IPaddresses of the remote interface components of said internetworkingsystems, level of confidences of the internetworking network connection,and at least one identification of physical characteristics, such as thegeographical distance of the connection between said interfacingcomponent and said similar interface component.
 13. The interfacecomponent according to claim 12 wherein said first interface module(RRI) is configured to exchange information with said at least onesimilar interface component via an IP transportation protocol such asthe TCP protocol.
 14. The interface component according to claim 12wherein said core (RRP) and said first interface module (RRI) areconfigured to exchange signals indicating quantities selected from thefollowing group: URL identifying the content to which the messagerefers, IP address of the cache which distributes the content, ID of theContent Delivery Network to which the cache belongs, cache state,content state in the cache, and life time of routing data.
 15. Theinterface component according to claim 8 wherein said fourth interfacemodule (MII) is configured to transfer to said core (RRP) signalsindicating quantities from the following group comprising: IP address ofthe cache to which the message refers, percentage of CPU used by thecache, percentage of RAM used by the cache, percentage of disc used bythe cache, percentage of users connected in relation to the maximumcapacity of the involved cache service.
 16. The interface componentaccording to claim 8 wherein said third interface module (DII) isconfigured to send to said core (RRP) signals indicating quantities fromthe following group comprising: URL identifying the content to which themessage refers, list of IP addresses of the caches of said content,level of confidence of said content, level of availability of saidcontent, cache state, life time of routing data.
 17. The interfacecomponent according to claim 16 wherein said quantity identifying thelevel of confidence of the content is susceptible of assuming distinctlevels corresponding to at least one first level of confidence in thegroup comprising: a first level of confidence indicating that thecontents may be exchanged by all networks in said set of networks, and asecond level of confidence indicating that the contents may be exchangedon by a selectively determined subset of networks in said set ofnetworks.
 18. The interface component according to claim 17 whereinsecond interface module (DNSI) is configured to communicate with theDirectory Name Server (DNS) to update respective tables on the basis ofsignals indicating quantities from the following group comprising: ID ofthe operation to be carried out on the table of said server, such asaddition or deletion, type of register, name of the domain to which themessage refers, entire URL of the content to which the message refers,IP address of the best cache to serve said domain, and life time of theregister.
 19. The interface component according to claim 18 wherein saidcore module comprises a memory hosting a data structure containinginformation on the state of the respective Content Delivery Network andsimilar internetworking networks.